In communication networks, such as telecommunication networks, a call or a service often involves, on the one hand, a control plane or signalling plane and, on the other hand, a user plane or a media plane. The control plane or signalling plane is in charge of establishing and managing a connection between two points of the network. The user plane or media plane is in charge of transporting user data or service data. Network operators have the desire to define and enforce a set of rules in the network. A set of rules constitutes policies. A policy framework for managing and enforcing these policies usually includes at least three elements or functions: a policy repository for storing policy rules, which may be user specific, a policy decision element or function and a policy enforcement element or function. The purpose of a policy framework includes controlling subscriber access to networks and services as well as the kind of access, i.e. its characteristics.
A policy framework notably addresses the decision as to whether the subscriber is entitled, or authorized, to enjoy a service, and whether the network can provide the service to the subscriber, and particularly whether the network can provide the service to the subscriber with a desired Quality of Service (QoS).
Policy and charging control architectures, such as, but not limited to, the architecture described in 3GPP TS 23.203 version 11.1.0 (2011-03), Technical Specification Group Services and System Aspects; Policy and charging control architecture (release 11) (available on http://www.3gpp.org/ftp/Specs/2011-03/Rel-11/23_series/), integrate policy and charging control. The Policy and Charging Control (PCC) architecture permits to integrate both policy and charging control. One aim of a policy framework is to set up and enforce rules dependent on subscribers and/or desired services to ensure efficient usage of network resources among all subscribers.
An architecture that supports Policy and Charging Control (PCC) functionality is depicted in FIG. 1 which is taken from 3GPP TS 23.203 specifying the PCC functionality for Evolved 3GPP Packet Switched domain including both 3GPP accesses (GERAN/UTRAN/D-UTRAN) and Non-3GPP accesses. The Policy Control and Charging Rules Function (PCRF) 110 is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding Service Data Flow (SDF) detection, gating, QoS and flow based charging (except credit management) towards the Policy and Charging Enforcement Function (PCEF) 120. The PCRF receives session and media related information from the Application Function (AF) 140 and informs the AF of traffic plane events. The PCRF 110 is also coupled to a Subscriber Profile Repository (SPR) 150.
The PCRF provides PCC Rules to the PCEF via the Gx reference point and may provide QoS Rules to the Bearer Binding and Event Reporting Function (BBERF) 130 via the S7x reference point.
The Gx reference point or interface is defined in 3GPP TS 29.212 “Policy and charging control over Gx reference point”, and lies between the PCRF and the PCEF. The reference point is used for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both.
The Rx reference point is defined in 3GPP TS 29.214 “Policy and charging control over Rx reference point” and is used to exchange application level session information between the PCRF and the AF. An example of PCRF is the Ericsson Service-Aware Policy Controller (SAPC), see for example F. Castro et al., “SAPC: Ericsson's Convergent Policy Controller”, Ericsson review No. 1, 2010, pp. 4-9. An example of an AF is the IP Multi-Media Subsystem (IMS) Proxy Call Session Control Function (P-CSCF).
Both Gx and Rx reference points may be based on Diameter, see for example P. Calhoun et al., “RFC 3588: Diameter Based Protocol”, IETF, September 2003.
In the architecture 100 of FIG. 1, the PCRF informs the PCEF through the use of PCC rules, for example, how to control the radio resources of the telecommunications network. For example, IP packets constituting traffic in the network are assigned to bearer resources.
The node including the PCEF or another Bearer Binding Function (BBF) encompasses SDF detection based on filter definitions included in PCC rules, as well as online and offline charging interactions and policy enforcement. Since the PCEF is usually the one handling bearers, it is where the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. For example, the PCEF is located at a gateway, such as the Gateway GPRS Support Node (GGSN), in the GPRS case. For all the cases where there is Proxy Mobile IP (PMIP) or Dual-Stack Mobile IP (DSMIP) in the core network, the bearer control is performed in the BBERF instead.
The Application Function (AF) 140 is an element offering applications in which service is delivered in a different layer, e.g. transport layer, from the one the service has been requested, e.g. signalling layer. The control of resources, such as, but not limited to, IP bearer resources, is performed according to what has been negotiated. One example of a network node including an AF 140 is the P-CSCF of the IP Multi-Media (IM) Core Network (CN) subsystem. The AF 140 may communicate with the PCRF 110 to transfer dynamic session information, i.e. description of multi-media to be delivered in the transport layer. This communication is performed using the above-described Rx interface or Rx reference point, which is placed between the PCRF 110 and the AF 140 and is used to exchange application level information between the PCRF 110 and the AF 140. Information in the Rx interface may be derived from the session information in the P-CSCF and it mainly includes what is called media components. A media component is composed by a set of IP flows, each one described through a 5-tuple, the media type and bandwidth required, for example. Another example of a network node including an AF 140 is a streaming server.
The PCRF 110 may also contact the SPR 150 to obtain subscription data. The SPR may contain information about the subscriber and its policies. If a user is a “premium” subscriber and is permanently able to have bandwidths larger than the average user and/or sessions of this user are connected with high QoS.
Upon reception of the PCC/QoS rule from the PCRF, the PCEF or the BBERF perform bearer binding, i.e. associate the provided rule to an IP-CAN bearer within an IP-CAN (Internet Protocol Connectivity Access Network) session. The bearer binding function will use the QoS parameters provided by the PCRF to create the bearer binding for the rule. The binding is created between service data flows included in the PCC/QoS rule and the IP-CAN bearer which have the same QoS Class Identifier (QCI) and Allocation Retention Priority (ARP).
Generally, the bearer binding function will evaluate whether it is possible to use one of the existing IP-CAN bearers or not. If none of the existing bearers can be used, the establishment of a suitable IP-CAN bearer is initiated. Otherwise, if required, e.g. QoS information has changed, the BBF will initiate the modification of a corresponding bearer. For GBR bearers, i.e. bearers with a guaranteed bit rate, the BBF will reserve the required resources based on the QoS information provided by the PCRF.
Next, PCC support to applications is described. When an application requires dynamic policy and/or charging control over the IP-CAN user plane to start a service session, the AF communicates with the PCRF to transfer the dynamic session information required for the PCRF to take the appropriate actions on the IP-CAN network. The PCRF authorizes the session information, creates the corresponding PCC/QoS rules and installs them in the PCEF/BBERF. The applicable bearer will be initiated/modified and if required, resources will be reserved for that application.
Once the application or the user equipment (UE) decides to terminate that service, the AF communicates the PCRF so that the PCRF can remove the applicable PCC/QoS rules and the PCEF/BBERF stops the corresponding SDF detection, policy enforcement and flow based charging functionalities, terminating or updating the applicable bearer, and releasing the corresponding resources.
An application server including the AF, such as a streaming server, may request establishment of a bearer from the PCRF according to its requirements, i.e. video or other streaming services requiring specific bandwidths, QoS, charging, etc.
Deep Packet inspection (DPI) technology supports packet inspection and service classification, which consists of IP-packets classified according to a configured tree of rules so that they are assigned to a particular service session. DPI is currently under standardization, as the so-called Traffic Detection Function (TDF), which can be either standalone or collocated with the PCEF, wherein traffic is captured by this function for packet inspection. The data traffic captured by the TDF is usually IP-packet data. For details, it is referred to 3GPP TR 23.813.
Currently, most existing UEs do not have support for dedicated bearers. Therefore, all traffic, i.e. all data traffic of the services the user is running, goes into the default bearer and it is not possible to assign different QoS for each service the user is running. This problem applies both to the standalone TDF and to the TDF collocated with a PCEF.
For example, in case of a sponsored service, the default bearer QoS is upgraded, e.g. by means of changing QCI or ARP, which have been described above, which means that other non-sponsored services on the same default bearer also experience the upgraded QoS. Therefore, the non-sponsored services will get a “free ride”, i.e. the same upgraded QoS without any sponsoring. When the sponsored service stops, the default bearer QoS goes back to the previous (non-boosted) QoS.
Some services/protocols like RTSP (Real Time Streaming Protocol) indicate a service stop condition in their own signalling (RTSP.TEARDOWN), but the majority of services, e.g. I-ITTP browsing, do not have such an indication, so a service stop condition needs to be based on inactivity timers handled locally by the TDF. This is an internal TDF functionality not defined in 3GPP and the external effect is that the event (service stop) is used to trigger the modification of the bearer resources, such as bearer QoS. Inactivity timers are usually set to very high values, so that the upgraded QoS remains for a very long time, even if the user is not running the sponsored service anymore. Accordingly, other non-sponsored services are taking a “free ride” during that period of time until the sponsored service session times out.
The same applies in the opposite scenario, for services which need to be downgraded in QoS. For example, the operator does not allow mobile IP telephony, such as Skype, on the UE and would like to downgrade the QoS of the service. If the user stops the mobile IP telephony session, the inactivity timer for that service session would still be running, so that the QoS remains downgraded for all services and the other services, which are not to be downgraded, also still experience a lower QoS, while this is not desired.
Since resources are limited in the network an optimized use of them is a requirement for the network operator, resources, and in particular bearer resources, have to be controlled efficiently. Therefore, there is a desire to provide efficient, flexible and/or fair resource allocation to services.